Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix wrap around on out of order packet #210

Merged
merged 2 commits into from
Oct 16, 2023

Conversation

boks1971
Copy link
Contributor

Sequence number cycle calculation was over estimating the cycles if packets came out of order. A sequence like 65535, 0, 65534 would increment the cycle counter twice.

Sequence number cycle calculation was over estimating the cycles
if packets came out of order. A sequence like 65535, 0, 65534 would
increment the cycle counter twice.
Copy link
Member

@davidzhao davidzhao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lg!

@codecov
Copy link

codecov bot commented Oct 16, 2023

Codecov Report

All modified lines are covered by tests ✅

Files Coverage Δ
pkg/report/receiver_stream.go 90.72% <100.00%> (ø)

... and 2 files with indirect coverage changes

📢 Thoughts on this report? Let us know!.

@boks1971 boks1971 merged commit 69a58bb into master Oct 16, 2023
16 checks passed
@boks1971 boks1971 deleted the raja_receiver_report_wrap_around branch October 16, 2023 15:51
@adriancable
Copy link
Contributor

adriancable commented Oct 16, 2023

@boks1971 - immediately after the lines of code you've changed is this:

// set missing packets as missing
for i := stream.lastSeqnum + 1; i != pktHeader.SequenceNumber; i++ {
	stream.delReceived(i)
}

I may be having a real bad code comprehension day, but this doesn't seem right. pktHeader.SequenceNumber is the 'non-unwrapped' sequence number, so if for example we have the packet sequence 65533, 65534, 3, 4, 5, ... then when we receive packet with sequence number 3, stream.lastSeqnum will be 65534, pktHeader.SequenceNumber will be 3 and so the for loop won't execute at all, and we won't call delReceived on the missing packets 65535, 0, 1, 2.

Don't we need something like this instead?

for i := uint32(stream.lastSeqnum) + 1; i != uint32(stream.seqnumCycles)<<16 | uint32(stream.lastSeqnum); i++ {

@boks1971
Copy link
Contributor Author

@boks1971 - immediately after the lines of code you've changed is this:

// set missing packets as missing
for i := stream.lastSeqnum + 1; i != pktHeader.SequenceNumber; i++ {
	stream.delReceived(i)
}

I may be having a real bad code comprehension day, but this doesn't seem right. pktHeader.SequenceNumber is the 'non-unwrapped' sequence number, so if for example we have the packet sequence 65533, 65534, 3, 4, 5, ... then when we receive packet with sequence number 3, stream.lastSeqnum will be 65534, pktHeader.SequenceNumber will be 3 and so the for loop won't execute at all, and we won't call delReceived on the missing packets 65535, 0, 1, 2.

Don't we need something like this instead?

for i := uint32(stream.lastSeqnum) + 1; i != uint32(stream.seqnumCycles)<<16 | uint32(stream.lastSeqnum); i++ {

It should be fine @adriancable as the types are uint16. i will be uint16 and looping over it means it will loop through 65535, 0, 1, 2. That pattern is used in a lot of places for wrap around handling.

@adriancable
Copy link
Contributor

@boks1971 - you are absolutely right of course! Thank you for fixing my bad code comprehension day. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants